Overall, I think this is the right approach to getting module compatibility for these functions.

My one concern is if this could lead to more things being #included everywhere, because it's adding the #include to class_db.hpp, which any GDExtension class would need to include. But it's possible that something is already pulling in utility_functions.hpp everywhere and so it would make no difference? This should be looked into

I had that concern too, but I don't see a way around it, so long as we want these to be lightweight wrappers around the functions in UtilityFunctions. Anyway, it's not really even a bad thing to have utility_functions.hpp included. These functions are very general and are available in engine modules anyway.

The dependencies of utility_functions.hpp are variant.hpp which is already included in class_db.hpp through object.hpp, builtin_types.hpp which is already included from variant.hpp, and <array> which is already included from variant.hpp, so including utility_functions.hpp in class_db.hpp only adds what's in utility_functions.hpp, no additional transitive dependencies.

I can confirm utility_functions isn't part of any common include yet - any time i need to debug print i currently have to include it explicitly. Including it "by default" would actually reduce friction (in my workflow anyway).

Cherry-picked for 4.3 in PR #1695